
\chapter{Go FAQs}
\label{chap:gofaq}

\section{Origins}

\subsection{What is the purpose of the project?}


No major systems language has emerged in over a decade, but over that time
the computing landscape has changed tremendously. There are several trends:
\begin{itemize}
\item 
Computers are enormously quicker but software development is not faster.
\item 
Dependency management is a big part of software development today but the
``header files'' of languages in the C tradition are antithetical to clean
dependency analysis---and fast compilation.
\item 
There is a growing rebellion against cumbersome type systems like those of
Java and C++, pushing people towards dynamically typed languages such as
Python and JavaScript.
\item 
Some fundamental concepts such as garbage collection and parallel computation
are not well supported by popular systems languages.
\item 
The emergence of multicore computers has generated worry and confusion.
\end{itemize}

We believe it's worth trying again with a new language, a concurrent,
garbage-collected language with fast compilation. Regarding the points above:

\begin{itemize}
\item 
It is possible to compile a large Go program in a few seconds on a single computer.
\item 
Go provides a model for software construction that makes dependency
analysis easy and avoids much of the overhead of C-style include files and
libraries.
\item 
Go's type system has no hierarchy, so no time is spent defining the
relationships between types. Also, although Go has static types the language
attempts to make types feel lighter weight than in typical OO languages.
\item 
Go is fully garbage-collected and provides fundamental support for
concurrent execution and communication.
\item 
By its design, Go proposes an approach for the construction of system
software on multicore machines.
\end{itemize}

\subsection{What is the origin of the name?}


``Ogle'' would be a good name for a Go debugger.

\subsection{
What kind of a name is 6g?}


The \texttt{6g} (and \texttt{8g} and \texttt{5g}) compiler is named in the
tradition of the Plan 9 C compilers, described in
\url{http://plan9.bell-labs.com/sys/doc/compiler.html}\footnote{See URL http://plan9.bell-labs.com/sys/doc/compiler.html}
(see the table in section 2).
\texttt{6} is the architecture letter for amd64 (or x86-64, if you prefer), while
\texttt{g} stands for Go.

\subsection{Why not just write some libraries for C++ to do communication?}


We considered doing that, but too many of the problems ---lack of \\
\emph{garbage collection},\emph{long dependency chains},\emph{nested include files}, 
\emph{lack of concurrency awareness} ---are rooted in the design of the C and C++ languages themselves.

We felt a viable solution required a more complete approach.

\section{Usage}


\subsection{Who should use the language?}


Go is an experiment. We hope adventurous users will give it a try and see
if they enjoy it. Not every programmer will, but we hope enough will
find satisfaction in the approach it offers to justify further development.

\subsection{ Is Google using Go internally?}

The Go project was conceived to make it easier to write the kind
of servers and other software Google uses internally, but the
implementation isn't quite mature enough yet for large-scale
production use.  While we continue development we are also doing
experiments with the language as a candidate server environment.  It's
getting there.  For instance, the server behind \url{http://golang.org}\footnote{See URL http://golang.org} is a Go program; in
fact it's just the \texttt{godoc} document server running in a
production configuration.

\subsection{Do Go programs link with C/C++ programs?}


There are two Go compiler implementations, \texttt{6g} and friends, generically called
\texttt{gc}, and \texttt{gccgo}.
\texttt{Gc} uses a different calling convention and linker and can
therefore only be linked with C programs using the same convention.
There is such a C compiler but no C++ compiler. \texttt{Gccgo} is a
GCC front-end that can, with care, be linked with GCC-compiled
C or C++ programs. However, because Go is garbage-collected it will be
unwise to do so, at least naively.

There is a ``foreign function interface'' to allow safe calling of C-written
libraries from Go code.  We expect to use \index{SWIG} to extend this capability
to C++ libraries.  There is no safe way to call Go code from C or C++ yet.

\subsection{Does Go support Google's protocol buffers ?}


Protocol buffers \footnote{See URL http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html} are supported.  We plan to have the next release of the
protocol buffer source code include Go code generators
and a Go library for them. The implementation uses data reflection
at run time so it is slow, but a new implementation is planned.

\section{Design}


\subsection{Why doesn't Go have feature X?}

Every language contains novel features and omits someone's favorite
feature. Go was designed with an eye on felicity of programming, speed of
compilation, orthogonality of concepts, and the need to support features
such as concurrency and garbage collection. Your favorite feature may be
missing because it doesn't fit, because it affects compilation speed or
clarity of design, or because it would make the fundamental system model
too difficult.

If it bothers you that Go is missing feature \textsl{X},
please forgive us and investigate the features that Go does have. You might find that
they compensate in interesting ways for the lack of \textsl{X}.

\subsection{Why is the syntax so different from C++?}


This and other language design questions are answered in the separate
language design FAQ in ~\ref{chap:golangfaq} on Page ~\pageref{chap:golangfaq}.


\section{Object-Oriented Programming}


\subsection{Is Go an object-oriented language ?}


Yes and no. Although Go has types and methods and allows an
object-oriented style of programming, there is no type hierarchy.
The concept of ``interface'' in Go provides a different approach that
we believe is easy to use and in some ways more general. There are
also ways to embed types in other types to provide something
analogous---but not identical---to subclassing.
Moreover, methods in Go are more general than in C++ or Java:
they can be defined for any sort of data, not just structs.

Also, the lack of type hierarchy makes ``objects'' in Go feel much more
lightweight than in languages such as C++ or Java.

\subsection{How do I get dynamic dispatch of methods ?}

The only way to have dynamically dispatched methods is through an
interface. Methods on structs or other types are always resolved statically.

\section{Concurrent programming}


\subsection{What operations are atomic? What about mutexes ?}


We haven't fully defined it all yet, but some details about atomicity
are available in the Go Memory Model specification.
Also, some concurrency questions are answered in more detail in the
language design FAQ in Chapter ~\ref{chap:golangfaq} on ~\pageref{chap:golangfaq}. \\

Regarding mutexes, the sync package implements them, but we hope Go
programming style will encourage people to try higher-level
techniques. In particular, consider structuring your program so that
only one goroutine at a time is ever responsible for a particular
piece of data.


\emph{Do not communicate by sharing memory}. Instead, \emph{share memory by communicating}.

\section{Writing Code}


\subsection{How are libraries documented ?}


There is a program, \texttt{godoc}, written in Go, that extracts
package documentation from the source code. It can be used on the
command line or on the web. An instance is running at
http://golang.org/pkg/\footnote{See URL http://golang.org/pkg/}.
In fact, \texttt{godoc} implements the full site at
http://golang.org/\footnote{See URL http://golang.org/}.

\subsection{Is there a Go programming style guide ?}


Eventually, there may be a small number of rules to guide things
like naming, layout, and file organization.
The document Effective Go in Chapter \ref{chap:goeffective} on page
\pageref{chap:goeffective} contains some style advice.
More directly, the program \texttt{gofmt} is a pretty-printer
whose purpose is to enforce layout rules; it replaces the usual
compendium of do's and don'ts that allows interpretation.
All the Go code in the repository has been run through \texttt{gofmt}.

\subsection{How do I submit patches to the Go libraries ?}

The library sources are in \texttt{go/src/pkg}.
If you want to make a significant change, please discuss on the mailing list before embarking.

See the document Contributing to the Go project in Chapter
\ref{chap:contribute} on Page \pageref{chap:contribute} for more information about how to proceed.

\subsection{How do I create a \index{multifile package} ?}

Put all the source files for the package in a directory by themselves.
Source files can refer to items from different files at will; there is
no header file or need for forward declarations.

Other than being split into multiple files, the package will compile and test
just like a single-file package.

\subsection{How do I write a unit test ?}


Create a new file ending in \texttt{\_test.go} in the same directory
as your package sources. Inside that file, \texttt{import {\tt{}"{}}testing{\tt{}"{}}}
and write functions of the form
\begin{verbatim} 
func TestFoo(t *testing.T) {
    ...
}
\end{verbatim}

Run \texttt{gotest} in that directory.
That script finds the \texttt{Test} functions, builds a test binary, and runs it.

\subsection{Where is assert ?}
\label{subsect:assert}
Go doesn't provide \index{assertions}. They are undeniably convenient, but our
experience has been that programmers use them as a crutch to avoid thinking
about proper error handling and reporting. Proper error handling means that
servers continue operation after non-fatal errors instead of crashing.
Proper error reporting means that errors are direct and to the point,
saving the programmer from interpreting a large crash trace. Precise
errors are particularly important when the programmer seeing the errors is
not familiar with the code.

The same arguments apply to the use of \texttt{assert()} in test programs. Proper
error handling means letting other tests run after one has failed, so
that the person debugging the failure gets a complete picture of what is
wrong. It is more useful for a test to report that
\texttt{isPrime} gives the wrong answer for 2, 3, 5, and 7 (or for
2, 4, 8, and 16) than to report that \texttt{isPrime} gives the wrong
answer for 2 and therefore no more tests were run. The programmer who
triggers the test failure may not be familiar with the code that fails.
Time invested writing a good error message now pays off later when the
test breaks.

In testing, if the amount of extra code required to write
good errors seems repetitive and overwhelming, it might work better as a
table-driven test instead.
Go has excellent support for data structure literals.

We understand that this is a point of contention. There are many things in
the Go language and libraries that differ from modern practices, simply
because we feel it's sometimes worth trying a different approach.

\section{Implementation}


\subsection{What compiler technology is used to build the compilers ?}


\texttt{Gccgo} has a C++ front-end with a recursive descent parser coupled to the
standard GCC back end. \texttt{Gc} is written in C using \texttt{yacc}/\texttt{bison} for the parser.
Although it's a new program, it fits in the Plan 9 C compiler suite
(\url{http://plan9.bell-labs.com/sys/doc/compiler.html}\footnote{See URL http://plan9.bell-labs.com/sys/doc/compiler.html})
and uses a variant of the Plan 9 \index{loader} to generate ELF binaries.

We considered writing \texttt{6g}, the original Go compiler, in Go itself but
elected not to do so because of the difficulties of bootstrapping and
especially of open source distribution---you'd need a Go compiler to
set up a Go environment. \texttt{Gccgo}, which came later, makes it possible to
consider writing a compiler in Go, which might well happen. (Go would be a
fine language in which to implement a compiler; a native \index{lexer} and
\index{parser} are already available in \texttt{/pkg/go}.)

We also considered using \index{LLVM} \footnote{See URL http://llvm.org/} for \texttt{6g} but we felt it was too large and slow to meet our performance goals.

\subsection{How is the runtime implemented ?}


Again due to bootstrapping issues, the runtime is mostly in C (with a
tiny bit of assembler) although Go is capable of implementing most of
it now. \texttt{Gccgo}'s runtime uses \texttt{glibc}.
\texttt{Gc} uses a custom library, to keep the footprint under
control; it is compiled with a version of the Plan 9 C compiler that supports
segmented stacks for goroutines.
Work is underway to provide the same stack management in
\texttt{gccgo}.



\subsection{How is src directory organized ?}

From the src directory:
\begin{enumerate}
\item cmd \\ go compilers and support utilities

\item lib9 \\ since the go source code is written using Plan 9 C, it also
makes sense to have useful bits imported. Plan 9 supports utf-8 in
everything, so there's a UTF-8 library in there; additionally a fmt
library for handling printf formatting and registering extensions to
it. 
\item libbio \\ 
 routines ; this is also originally from plan 9

\item libcgo \\ machine$\textbackslash$architecture support for cgo.

\item libmach \\ machine-specific bits for various things in cmd

\item misc \\ self-explanitory ; miscellany

\item pkg \\ packages$\textbackslash$apis for Go, some of these are worth mentioning specifically:

\item pkg$\textbackslash$ debug \\ contains some machine\textbackslash arch specific go code that is used for ogle

\item pkg$\textbackslash$ runtime \\ the go runtime. this is the core of language support,
handles os-level threading, memory allocation, garbage collection, and
the like

\item pkg$\textbackslash$ syscall \\ syscall interfaces for the OS, including some
architecture-specific code. the heart of it is a set of scripts that
is used to auto-generate some of these interfaces, though some
hand-written code is necessary

\item tests \\ various regression tests and bits of code demonstrating
various language bugs for planned fixes 
\end{enumerate}

\subsection{Go for Arm CPU info}

Posted on \url{http://groups.google.com/group/golang-nuts/browse_thread/thread/a0216500e20e7dd7#}

Thanks to the great architecture, it's pretty easy to cross compile Go
toolchain. If the target happens to be little endian arm, we have a
``native'' 5* toolchain that can run on the device.

The cross build recipe is at \url{http://trac.nslu2-linux.org/optware/browser/trunk/make/golang.mk}

The resulting binaries here\url{ http://ipkg.nslu2-linux.org/feeds/optware/}
(for arm and i686 feeds including some uclibc targets). There are a
lot of devices that can use these feeds - Linksys nslu2 with slugos5le
or debian firmware (cs08q1armel), Marvell SheevaPlug, QNAP, Synology,
Buffalo,WD,Maxtor, D-link NAS, Palm Pre phone. Unfortunately soft
floating point does not work yet on ARM so right now you'd need to use
println() instead of fmt.

After installing the \index{ipk}, you'll need to set 
\begin{verbatim}
GOOS=linux 
GOARCH=arm
GOROOT=\opt\share\go 
GOBIN=\opt\share\go\bin
PATH=$GOBIN:$PATH.
\end{verbatim}
Cheers,

-Brian 


\subsection{Compassion of Simple Hellow world exe size}


Posted on \url{http://groups.google.com/group/golang-nuts/browse_thread/thread/4df3d6012e3ff2ed/995aae04f5f7e36b?lnk=gst&q=size#995aae04f5f7e36b}
\begin{verbatim}
; cat >x.c
#include <stdio.h>

int main(void) {
        printf(``hello, world\n'');
        return 0;
}

; gcc -static x.c
; ls -l a.out
-rwxr-x--- 1 rsc eng 665642 Nov 11 00:19 a.out
; size a.out
   text    data     bss     dec     hex filename
 573031    3424   12296  588751   8fbcf a.out
;

; cat >x.go
package main

import ``fmt''

func main() {
        fmt.Printf(``hello, world\n'');
}

; 6g x.go
; 6l x.6
; ls -l 6.out
-rwxr-x--- 1 rsc eng 634803 Nov 11 00:19 6.out
; size 6.out
   text    data     bss     dec     hex filename
 136145  225832 2180280 2542257  26cab1 6.out
; 

\end{verbatim}
